Kicksecure VM Build Documentation

Kicksecure ™

Download

On Computer USB Installation Debian morph to Kicksecure Windows (VM) Linux (VM) Mac (VM) VirtualBox (VM) KVM (VM) Qubes (VM) More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Instructions to build Kicksecure Virtual Machine Images from Source Code.

Introduction

This page documents how to build Kicksecure VM (Virtual Machine) images for VirtualBox (.ova) or KVM (.qcow2) "from source code". Most users do not build Kicksecure from source code but instead download Kicksecure.

For Kicksecure for Qubes, see Kicksecure for Qubes Build Documentation.

Building from source code as security advantages (see Trust).

The goal of this build documentation is to be usable by as many users as possible. Therefore written as easy as possible with no prior knowledge of tools used required.

The high level summary is:

1. Host preparation.
2. Get derivative-maker source code.
3. Run derivative-maker.
4. Done, build of Kicksecure has been completed.

Advanced users that already know how to use git and how to perform digital software verification using OpenPGP (gpg) do not need to strictly follow this documentation. See footnote(s) for details.

Due to digital software verification instructions and Software Signature Verification Usability Issues these instructions might look more complicated then they actually are.

• Digital signatures are a tool enhancing download security. They are commonly used across the internet and nothing special to worry about.
• Optional, not required: Digital signatures are optional and not mandatory for using Kicksecure, but an extra security measure for advanced users. If you've never used them before, it might be overwhelming to look into them at this stage. Just ignore them for now.
• Learn more: Curious? If you are interested in becoming more familiar with advanced computer security concepts, you can learn more about digital signatures here digital software signatures.

Steps concerning digital software verification are pointed out as "This step is recommended for better security, but is not strictly required. (See Trust.)"

When verifying digital software signatures, these instructions will be slightly more complicated but therefore even more secure.

1. Host preparation.
2. Get Kicksecure source code (which includes Kicksecure build script).
3. Verify digital software signatures.
4. Run Kicksecure build script
5. Done, build of Kicksecure has been completed.

Host Preparation

Host Preparation Notices

Expand all Collapse all

• operating system: You need to build on a Debian bookworm based operating system, such as Kicksecure 17 or a Debian bookworm VM.
• disk space: You need ~ 30 GB free disk space.
• RAM: You need ~ 4 GB free RAM.
  • Might actually work with a lot less RAM.
  • Might actually work with less RAM if you have swap.
• linux user account: Do not build under user root. Login regular as user user. Do not use sudo to run derivative-maker because becoming root when necessary is handled by the build script.
• build place notice: You cannot build on Kicksecure (due to networking issues).
• build logs: Build logs: If using a GUI (graphical user interface) it is recommended to set your terminal (for example xfce4-terminal) to unlimited scrollback, so you can watch the full build log and share it for support in case there are issues.

...

• private files in source code warning: Do not add private files to Kicksecure source code folder! [...]

Unless you know what you are doing. Technically, it would work. This is recommended against. Those files would get managed by the respective package. When you later update Kicksecure debian packages, your files would get deleted by the package manager. Also adding private files to Kicksecure source code folder, later contributing to Kicksecure development and accidentally pushing the wrong git branch would be a disaster. Better add your private files to Kicksecure after building Kicksecure. Or add a custom build step adding your files, which then get copied from a folder outside of Kicksecure source folder. See "Source Code Changes" in "Optional Build Configuration" below.

• parallel builds unsupported warning: Do not try to build Kicksecure and Kicksecure at the same time!

Building Kicksecure and Kicksecure at the same time is not supported due to limitations in the build script. In other words, do not try to run for example ~/derivative-maker/derivative-maker --flavor whonix-gateway -- --target virtualbox and ~/derivative-maker/derivative-maker --flavor whonix-workstation -- --target virtualbox at the same time. The build would probably fail.

• CI warning: Do not use images created inside Continuous Integration (CI) environments for anything besides testing!

Usually you are not using CI environments without knowing.

You can find out if you are running inside a CI environment by running.

echo "$CI"

If it shows nothing, i.e.

Everything is fine.

Otherwise, if it were to show.

true

Then do not use these images for anything besides testing.

Reason: https://github.com/Kicksecure/derivative-maker/blob/master/build-steps.d/1200_prepare-build-machine

• official builds: In case of creating official builds to be redistributed on kicksecure.com and not for personal use, press expand on the right side.

Prepend the following variable: dist_build_redistributable=true

sets:

• --repo true
• --tb closed

See also: Dev/Redistribution

Host Preparation Steps

1. build dependencies:

Install build dependencies and get the source code.

Update the package lists.

sudo apt update

Install build dependencies.

sudo apt install git time curl apt-cacher-ng lsb-release fakeroot dpkg-dev fasttrack-archive-keyring safe-rm

2. Platform specific notices:

• VirtualBox: Install VirtualBox on the build machine as per recommended VirtualBox version.
• Other platforms: No special notice.

3. sudo setup:

Choose either Option A or Option B.

Option A: passwordless sudo

Option A: Set up passwordless sudo.

• Abstract task overview: Setup passwordless sudo for your Linux user account name.
• Detailed task overview: Setup sudo and add your current linux user account to the linux user group sudo. The following instructions use Linux user account name user as an example. If the user is using a different Linux user account name such as myname then the commands below have to be adjusted accordingly.
• Unspecific: Configuration of sudo is unspecific to Kicksecure.
• Kicksecure specific: When building inside Kicksecure, user user is already a member of group sudo by default. Therefore the following step "1." can be skipped.
• Detailed steps:

1. Setup sudoers. Add the operating system user name to sudoers.

Become root.

su

Add the user account to the sudoer's group. Replace user with the actual operating system user name.

sudo adduser user sudo

Reboot so group changes take effect.

reboot

2. Configure user user to be able to use sudo without a password.

echo '%sudo ALL=(ALL:ALL) NOPASSWD:ALL' | sudo EDITOR=tee visudo -f /etc/sudoers.d/dist-build-sudo-passwordless >/dev/null

3. Done.

The process of setting up passwordless sudo has been completed.

Option B: long sudo timeout

Option B: Set a longer sudo password timeout.

• Abstract task overview: Setup sudo with a longer timeout for your Linux user account name.
• Detailed task overview: Setup sudo and increase the sudo password timeout (four all Linux user accounts or all users). The following instructions use Linux user account name user as an example. If the user is using a different Linux user account name such as myname then the commands below have to be adjusted accordingly.
• Unspecific: Configuration of sudo is unspecific to Kicksecure.
• Kicksecure specific: When building inside Kicksecure, user user is already a member of group sudo by default. Therefore the following step "1." can be skipped.
• Detailed steps:

1. Setup sudoers. Add the operating system user name to sudoers.

Become root.

su

Add the user account to the sudoer's group. Replace user with the actual operating system user name.

sudo adduser user sudo

Reboot so group changes take effect.

reboot

2. Configure user user to be able to use sudo without a password.

echo 'Defaults timestamp_timeout=30' | sudo EDITOR=tee visudo -f /etc/sudoers.d/dist-build-sudo-timeout >/dev/null

3. Done.

The process of setting up a longer sudo timeout has been completed.

Special Notice

None.

Choose Version

Version Numbers Choice Information

1. Common sense is required when choosing the right version number.

2. For example, the latest available git tag version number is not necessarily the most stable or suitable.

3. Follow the Kicksecure News Blog as it might contain information.

4. This documentation will be using 17.2.3.7-stable as an example. Replace 17.2.3.7-stable with the actual version chosen for the build.

5. Git tags by convention:

• have one of the following appendixes stable, testers-only or developers-only version.
• For example:
  • 17.2.3.7-stable
  • 17.2.3.7-testers-only
  • 17.2.3.7-developers-only
• all represent the very same source code.

6. If there is only git tag 17.2.3.7-developers-only available but a stable release announcement has been published, then there is no need to wait for the creation of 17.2.3.7-stable since it actually has already been blessed stable, would contain the identical source code anyhow but just have a different git tag name.

Version Numbers Choice Instructions

1. Go to https://forums.kicksecure.com/c/news/ and look for the latest stable version number.

2. Compare with the stable version number mentioned in the wiki.

3. For example, if 17.2.3.7 has been announced in the forums and is available from the wiki, git tag 17.2.3.7-developers-only is avaialble but 17.2.3.7-stable is not, then 17.2.3.7-developers-only can be safely used.

Get the Signing Key

This step is recommended for better security, but is not strictly required. (See Trust.)

Get the Kicksecure Signing Key and import it.

Get the Source Code

FREE

Note: By proceeding, you acknowledge that you have read, understood and agreed to our Terms of Service and License Agreement.

1. Install git.

sudo apt update && sudo apt install git

2. Get the source code including git submodules.

Note: Replace 17.2.3.7-stable with the actual tag you want to build.

git clone --depth=1 --branch 17.2.3.7-stable --jobs=4 --recurse-submodules --shallow-submodules https://github.com/Kicksecure/derivative-maker.git

3. Check if above command succeeded.

If there have been errors such as:

fatal: unable to access 'https://github.com/.../': Could not resolve host: github.com

Or.

fatal: unable to access 'https://github.com/.../': gnutls_handshake() failed: The TLS connection was non-properly terminated. 

Then the download probably failed.

Checking if the download failed or succeeded can be done by checking the exit code.

Choose your shell.

Zsh in Kicksecure or Derivatives

If the last line contains something such as the following.

zsh: exit 1

Then do not proceed and see footnote.

bash and other Shells

Show the exit code.

echo $?

Output should show.

0

If any other exit code is shown, do not proceed and see footnote.

4. Done.

Git repository cloning has been completed.

Change Directory

Change directory to the derivative-maker source code folder because later on package build commands using ./derivative-maker are expected to be run from the root of the source folder.

cd derivative-maker

OpenPGP Verify the Source Code

This chapter is recommended for better security, but is not strictly required. (See Trust.)

• Digital signatures are a tool enhancing download security. They are commonly used across the internet and nothing special to worry about.
• Optional, not required: Digital signatures are optional and not mandatory for using Kicksecure, but an extra security measure for advanced users. If you've never used them before, it might be overwhelming to look into them at this stage. Just ignore them for now.
• Learn more: Curious? If you are interested in becoming more familiar with advanced computer security concepts, you can learn more about digital signatures here digital software signatures.

1. Verify the chosen tag to build.

Note: Replace with tag you want to build.

git verify-tag 17.2.3.7-stable

2. Check the output of the verification step.

If the file is verified successfully, the output will include Good signature, which is the most important thing to check.

gpg: Good signature

This output might be followed by a warning as follows.

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

This message does not alter the validity of the signature related to the downloaded key. Rather, this warning refers to the level of trust placed in the Kicksecure signing key and the web of trust. To remove this warning, the Kicksecure signing key must be personally signed with your own key.

Remember to check the GPG signature timestamp. For instance, if you previously saw a signature from 2023 and now see one from 2022, this could indicate a potential rollback (downgrade) or indefinite freeze attack.

2. Verify the git commit to build.

Note: Replace 17.2.3.7 with the actual git tag being verified.

git verify-commit 17.2.3.7-stable^{commit}

3. Check the output of the verification step.

4. Done.

Checkout Version

1. Retrieve a list of available git tags.

git --no-pager tag

2. Use git checkout to select the preferred version to build.

Note: Replace 17.2.3.7-stable with the actual version chosen for the build: the stable, testers-only or developers version. Common sense is required when choosing the right version number. For example, the latest available version number is not necessarily the most stable or suitable. Follow the Kicksecure News Blog as it might contain information.

git checkout --recurse-submodules 17.2.3.7-stable

3. Digital signature verification.

Optional. If you choose to perform digital signature verification above, you could verify the currently chosen commit ("HEAD") yet again for extra security.

git verify-commit HEAD

4. Done.

Version selection has been completed.

Check Git

1. Check if you really got the version you want.

git describe

The output should show.

17.2.3.7-stable

2. Check if source folder is pristine.

git status

Output should be the following.

• A)

HEAD detached at 17.2.3.7-stable
nothing to commit, working tree clean
or,

• B)

Not currently on any branch.
nothing to commit, working tree clean

If it shows something else, do not continue.

3. Done.

Build

1. Build target selection.

Mandatory The following build targets are available.

Choose a --target. Either option A), B), C) or D).

Option	Build Target	Comment	Image Type	Target Parameter
A)	VirtualBox VMs	Stable.	.vdi	--target virtualbox
B)	KVM (and QEMU)	KVM: Stable.; QEMU: unsupported	.qcow2	--target qcow2
C)	raw images	Mostly interesting for developers / porters.	.raw	--target raw
D)	UTM with QEMU	Tested on Mac M1, M2, ... testers only, --arch arm64.	.raw	--target utm
E)	ISO	Testers only.	.iso	--target iso

2. Flavor selection.

Mandatory. Choose a flavor.

• --flavor kicksecure-cli
• --flavor kicksecure-xfce

3. CPU target architecture selection.

Mandatory. Choose a target CPU architecture.

Option	CPU Architecture Name	Comment	CPU Architecture Parameter
A)	Intel and AMD64	Default, best tested.	--arch amd64
B)	i386	Unsupported.	--arch i386
C)	ARM64	Unsupported.	--arch arm64
D)	Others.	Potentially.

4. Kicksecure APT repository choice.

Optional. Enable Kicksecure APT repository inside the images. See Trust. This is done for official Kicksecure redistributeable builds.

--repo true

5. Optional configurations.

Optional. See also Optional Build Configuration.

6. Notices.

• These instructions assume you have the Kicksecure source code in your home folder (~/derivative-maker), and
• use VirtualBox as an example.

7. build command:

• A) Build a Kicksecure virtual machine image.
  • ~/derivative-maker/derivative-maker --flavor kicksecure-xfce --target virtualbox --repo true
• B) Build a Kicksecure ISO image.
  • ~/derivative-maker/derivative-maker --flavor kicksecure-xfce --target iso --repo true

---

While building, you might see a few Expected Build Warnings.

Build Logs

Optional.

Mostly useful in case of build issues where sharing the build log is necessary for support.

If using:

• A) GUI (graphical user interface): It is recommended to set your terminal (for example xfce4-terminal) to unlimited scrollback, so you can watch the full build log and share it for support in case there are issues.
• B) CLI (command line user interface): In case there are build issues, it is recommended to redirect the build log to a text file. To do that, for example >> ~/build-log 2>&1 could be appended to the very end of the build command to redirect the build output to build log file ~/build-log.
  • Note: when using that command there will be no output in the terminal until the build is completed. This is as per Linux default and unspecific to Kicksecure. The build might not complete. In that case, that command would hang forever. To see if the build is stuck, it would be possible to open the build log file with a text editor. In that case, the file would have to be re-opened or refreshed to with F5 key to see new build output appended to the build log file. Or by using for example tail -n 100 -f ~/build-log 2>&1

VM Build Result

• VirtualBox: The resulting .ova images can be found in ~/derivative-binary folder.
• KVM, QEMU, raw images: The resulting .qcow2 and/or .raw images can be found in ~/derivative-binary folder.
• ISO: The resulting .iso image can be found in ~/derivative-binary folder.

Most users have completed the build process at this point, can start using Kicksecure and skip the rest of this page.

Prepare Release

dm-prepare-release is useful for:

• Creation of a unified .ova image or libvirt.xz archive
• Creation of torrent files.
• Creation of hash sum files.
• Creation of digital software signatures.
  • OpenPGP (gpg) signatures
  • signify signatures
  • soon Codecrypt signatures
• Adding the license agreement.
• Adding the disclaimer.
• Redistribution.
• Example: dm-prepare-release --build --target virtualbox --flavor kicksecure-xfce

For private builds, i.e. for builds which are not supposed to be redistributed to others, none of this is important. If any of this was important, it could also be done manually.

Troubleshooting

Build repeatedly errors out with hash sum mismatch

If corrupted data is present on a Debian mirror during a build, apt will generate a hash sum mismatch error which will cause the build to fail. apt-cacher-ng will also have cached the corrupted file, meaning all subsequent builds will fail until apt-cacher-ng's cache is purged.

To purge the cache:

sudo systemctl stop apt-cacher-ng sudo rm -rf /var/cache/apt-cacher-ng sudo mkdir /var/cache/apt-cacher-ng sudo chown apt-cacher-ng:apt-cacher-ng /var/cache/apt-cacher-ng sudo systemctl start apt-cacher-ng sudo systemctl status apt-cacher-ng

If apt-cacher-ng's status is active (running) after this, the cache purge is successful.

Footnotes

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!